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A DATA ACCESS, REPLICATION OR COMMUNICATION SYSTEM 
COMPRISING A DISTRIBUTED SOFTWARE APPLICATION 

5 FIELD OF THE INVENTION 

This invention relates to a data access, replication or co mmuni cation system comprising 
a distributed software application. 

10 DESCRIPTION OF THE PRIOR ART 

Wireless terminals, such as smartphones, mobile telephones, wireless PDAs etc, typically 
have severe memory, processing power and battery constraints. As a result, using 
terminals of this sort to access, replicate or communicate data presents, significant 

15 challenges. For example, if one uses the wireless terminal to store one's contacts and 
calendars and also send and receive e-mails, then, conventionally a requirement to 
synchronise datasets to a master dataset on a remote server arises. Synchronisation 
between servers and mobile devices traditionally takes place using relatively high 
bandwidth, low latency, un-metered connectivity (e.g., USB or IR). As a result, 

20 synchronisation systems often employ a methodology that transmits large amount of data 
and is not very robust when data is lost in transmission or the underlying transmission is 
interrupted. For example, server based dataset synchronisation typically requires all 
connected devices to download their entire datasets (e.g. all e-mails, all contacts etc) to the 
server over a single session, which can then perform a comparison against its master 

25 copy of the last fully synchronised dataset in order to update the master and hence all 
other datasets. This approach is unattractive for synchronising wireless devices because 
of the" power drain it imposes, the potentially long connection time and costly data 
transfer. 
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SUMMARY OF THE PRESENT INVENTION 

The present k^Q^aage^dat^ccess^We^o^^^ 

comprising ..software application that is distributed across a terminal-side component 
5 runmng on a terminal and a server-side component; • 

in which the terminal-side component and the server-side component ft together 
constitute a client to a server and (ii) coHaborate by sending messages using a message 
queuing system over a network. ~ 

0 Hence, we split (re. 4. to,,,^ of an application that serves aa me client 

in a client-sever configuration (for example, in - a Microsoft Exchange e-mail 
entnronment) into component parts mat rnn on two or more physical" deuces that 
commnnicate with each other over a network connection nsing a message opening 
system, such as message oriented middleware. The component par* collectively act as a 
• dtent m a larger dent-server a^angemen, with me server being, for example, the 
Exchange mail server. We can this a "Distributed Chenf model A core advantage of the 
Dtstnbured Client model is that it allows a terminal, such as mobfle device with limited 
processmg capacity, power, and connectivity, to enjoy use functionality of full-featured 
den, acceaa to a server environment using minimum resources on the mobile device by 
debuting some of the functionality normally associated with me client onto tire server 
stde, winch is not so resource constrained. (Whilst the present invention therefore has 
particular utility where the terminal is a wirefcas terminal (e.g. a sma«phone) and the 
network ts a wireless network (e.g. GPRS), i, is not limited to these embodiments It 
therefore also covers, for example, me terminal being a desktop PC communicating with 
a remote server over a wired network). 

Unlike other distributed models, in an implementation ofthe present invention each 
component part can provide functionality (that goes beyond merely accessing 
cached/stored data) independently of the other, even when the network connection is 
absent For example, in a conventional distributed client, such as e-mail web access 
usmg a web browser and a web server distributed client accessing a Microsoft Exchange 
mad server, if you break the connection between the browser and the web server then 
the browser has no functionality, other than to continue to display any cached e-mails. 
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But with an implementation of the present invention, the terminal-side component may 
also insulate a terminal program (e.g. contacts, calendar, e-mail etc) from being affected if 
the connection over the network is broken by also queuing messages in readiness for the 
connection to be re-established, enabling the terminal program to proceed to its next 
5 task. Hence, the user experience of using the e-mail or PIM applications on the terminal 
(e.g. smartphone, PC) is exacdy the same, whether there is a connection or not The user 
can continue to create e-mails, edit contacts etc. on his terminal. The user is insulated 
from the state of the network connection because the terminal can queue messages, 
using the message queuing system, until such time as the connection is re-established and 
10 can then automatically send them. Equally, the server-side component may insulate a 
server program from being affected if the connection over the network is broken by also 
queuing messages in readiness for the connection to be re-established, enabling the 
server program to proceed to its next task 

15 Because this approach facilitates making the terminal side insulated from the vagaries of 
network performance by interposing a message queuing platform across the network, it 
is also better when the network is a wireless network, with highly unpredictable 
bandwidth, coverage and availability. Hence, the Distributed Client model directly 
address the problem of providing a good user experience at the terminal (e.g. the end- 

20 user is always able to interact with his PIM, calendar and e-mail applications, irrespective 
of network coverage) despite the terminal having major resource constraints and despite 
the connection having major constraints. 

One implementation detail optimised for a Distributed* Client is that each queued 
25 message defines part or all of an 'event*, in which an event describes a change to the data 
stored at either the terminal or server in enough detail to enable data replication to take 
place without the need for a conventional synchronisation engine; data replication is 
hence achieved by sending Events', rather than a complete dataset (or sub-set of a 
dataset) of stored data for synchronisation. The terminal- side component can create 
30 events and queue those events, itself and/or in the message queuing system, enabling the 
terminal-side component to proceed to its next task, even if the network connection is 
broken. Equally, the server-side component can create events and queue those events, 
itself and/ or in the message queuing system, enabling the server-side component to 
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proceed to its next task, even if the network connection is broken. Queued events may 
persist in non-volatile memory on the terminal even when the wireless terminal is 

winch runs me-server-side component even when the server is switched ofFQt may be 
noted that the host which runs the server-side component is unlikely to be the same host 
that runs the server, although it could be). 



The terminal-side component and the server-side component may collectively constitute 
xmddleware between a terminal program running on the wireless terminal and a server 
10 program running on the server. 

The application may also comprise a distributed application platform that makes calls to 
a dtsmbuted communications platform that provides the message queuing functionality 
m whtch the communications platform enables delivery of a message over the network to 
be reltable, even if an unreliable transport protocol is used, in which the communications 
platform operates in a 'session independent' manner. 
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DET AILE D DESCRIPTION 
1. Introduction 

The present invention will be described with reference to an implementation from Psion 
5 Digital Limited of London, United Kingdom. The implementation comprises a 
middleware communications platform called MobileMQ™ and a distributed application 
layer called Transcend Mail™. 



Transcend Mail is an end-to-end GPRS-connected application that runs on (i.e. is 
10 distributed across both) a SymbianOS™ smartphone wireless terminal and a Windows 
2000 server. It allows an e-mail, contacts and calendar application on a SymbianOS 
smartphone to use the MobileMQ platform to perform automatic data replication over 
GPRS with a Microsoft Exchange™ mail server. MobileMQ is a message-oriented 
middleware platform that is again distributed across both the smartphone and the server. 
15 It provides the GPRS-efficient, reliable and secure means of communication that enables 
many aspects of Transcend Mail's user experience. MobileMQ can be used wherever 
there is a requirement for remote data access, replication or communication over a 
network (whether wired or wireless). MobileMQ uses an unreliable underlying transport 
protocol that is session independent. 

20 

Transcend Mail allows mobile workers to access their company email, contacts and- 
calendar entries from their Symbian-based GPRS smartphones. It is designed to meet 
three needs of the mobile worker: 

1. It enables them to remain c in-touch' whilst away from their desk, enabling them 
25 to be responsive to customer, market, and business needs. 

2. It ensures that their contacts and calendar remain 'up-to-date' so that these can 
effectively be co-ordinated with co-workers. 

3. It enables productive use to be made of 'dead-time* whilst between 

appointments, waiting for transport, or during travel. 

30 

Transcend Mail enables the following features: 

• Allows the terminal device user interface to work with local data so the GPRS 
latency, low and variable bandwidth and intermittent coverage does not stop the 



Distributed Client 



6 . 



e-mail, contacts and calendar applications from being always available and 
responsive 



10 



15 



a timely way and in background, without bothering the user " 
Be parsimonious in using GPRS so that the customer gets appropriate value from 
the network operator's GPRS tariff and does not get what is sometimes called 
"bill shock" 

Allows flexibility in the way that customer organisations connect their workers' 
GPRS mobile phones to the company LAN 

Integrate as seamlessly as possible with the mobile phone application suite so that 
the user does not have to learn a new systern" 

Integrate as seamlessly as possible with the back end email server so that the IT 
administrator is comfortable and has a good user experience too 
Different applications on the terminal device can send/receive independently, so 
that one can still update one's calendar even though downloading a very large e- 
mail attachment. 
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2. Core Design Principles 

In an implementation of the present invention, we split (Le. distribute) me functionality 
of the Transcend Mail application that serves as the client in a client-server configuration 
(for example, in a Microsoft Exchange environment) into component parts that run on 
two or more physical devices that communicate with each other over a wide area 
connection using the MobileMQ message oriented middleware. The component parts 
collecnvely act- as a client in a larger client-server arrangement, with the server being the 
Exchange mail server. We call this a distributed Clienf model. A core advantage of the 
Dxstidbuted Ghent model is that it allows a terminal, such as mobile device with limited 
processing capacity, power, and connectivity, to enjoy the functionality of full-featured 
client access to a server environment using minimum resources on the mobile device by 
distributing some of the functionality normally associated with the client onto the server 
side, which is not so resource constrained. 
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But unlik e other distributed models, in Transcend Mail, each component part can 
provide functionality (that goes beyond merely accessing cached/stored data) 
independently of the other, even when the network connection is absent. For example, 
in a conventional distributed client, such as e-mail web access using a web browser and a 
5 web server distributed client accessing a Microsoft Exchange mail server, if you break the 
connection between the browser and the web server then the browser has no 
functionality, other than to continue to display any cached e-mails. But with Transcend 
Mail, the user experience of using the e-mail or PIM (contacts, calendar) applications on 
the smartphone is exactly the same, whether there is a connection or not. The user can 

10 continue to create e-mails, edit contacts etc. on his smartphone. The user is insulated 
from the state of the network connection because the terminal can queue messages, 
using MobileMQ (and its own queue as well if the MobileMQ queue is full), until such 
time as the connection is re-established and can then automatically send the next queued 
message. Similarly, the next queued message stored server-side can be automatically sent 

15 when the connection is re-established. . 

This approach is also better when the network is a wireless network, with highly 
unpredictable bandwidth, coverage and availability because it facilitates making the 
terminal side insulated from the vagaries of network performance by interposing a 

20 message queuing platform (i.e. MobileMQ) across the network . Hence, the Distributed 
Client model directly address not only the problem of providing a good user experience 
at the terminal (e.g. always able to interact with his contacts, calendar, and e-mail 
applications, irrespective of network coverage) despite the terminal having major 
resource constraints and despite the connection having major constraints. This is 

25 schematically illustrated in Figure 1. 

The MobileMQ message oriented middleware (MOM) communications platform enables 
the component parts to effectively and efficiently store messages to be sent between 
component parts and actually send them reliably. The MobileMQ MOM enables 
30 message delivery over a network to be reliable, irrespective of whether the underlying 
transport protocol used is reliable or not; and independent of any session; The transport 
protocol is therefore referred to as 'session independent'. This again marks a major 
departure from normal networking protocols, such as WAP, which are session based. 
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Sess.cn .dependent' (as n 0K d earlier) before stands in contiaa. to session based 
Sesston baaed protocols teat down a aeasion when data transfer ra.es fall below a 

^^"^.timeorrtiThey^ 

of data-rrafflc, wbich ia (a) cosdy in a wireless system where users pay for the S^ff 
da. trananaitted and <b> not indent due to the highly variable bandwidth aaaociared 
wtth welesa networks. A session independent pro K col however does not deliberately 
tear down a connection. (We distingnish here situations where the underlying PDP 
content is merely leased or reassfened for use by other applications, oc the current 
undedytng PDP comes, is ,oa, or otherw^e tinrea out. In theae types of cases, the higher 
layer sesston-independent protocol merely suspends communication activity pending re- 
action of a PDP contest - i t doea no. need to re-establish a 'session., as such.) 

lie combination of MobileMQ MOM and aesaion independence addresses many 
connection constraint problems, as illustrated in Figure 2: 

Further, with a session independent protocol, mere ia no re-establishing of a session as 
such; tnstead, a sending component simply re-starK sending as soon as i, knows how to 
address its messages to the receiving component of the distributed client This ia 
especial* uaeful in the wireless conres, since a wireless device does no. (unless and until 
IPv6 is avaUable) have a permanent IP address a. all, but instead can only receive IP 
baaed messages via an arbitrary selected IP address that is frequently changed. Hence 
session independence ft, well me .elements of sending messages » wireless devices' 
warn tiansitory address, ye. wim me minimum of overhead heed to cope with these 
changmg addresses, aince it avoida me overhead of aession re-establishment. 

Transcend MaU also adopts -evenf baaed data replication - re. a log is hep. of all new 
even* which define a change » me da* stored on me dien. or me server sides and only 
tiaese even* are queued in a log. When a connection ia established between each side of 
me drstubu.ed client, men each queued even, (as represented by one or more message 
depending on the comply of the event) is sen, wim a single message being carried by 
one or more packes. Because MobileMQ allows tine efflcien. and reliable tiansfer of 
usages, it ia particularly well matched to an even, baaed da* replication system, which 
Itself requires no more than tire efficient and reliable transfer of messages 
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The higher level applications using the MOM have no awareness of connection status — 
Le. MobileMQ is a MOM layer that insulates applications using MobileMQ from needing 
to be aware of the existence or non-existence of an underlying connection (such as an 
5 active PDP context). At the application layer, the system is 'connection independent'. 
The term 'session independent* therefore equates at the application layer conceptually to 
a system in which there is a single session that persists independently of whether an 
actual connection is' established or not in the sense that, when a connection is re- 
established after a break, an application can re-commence message transfer at exacdy the 

10 same place where it ceased — i.e. the next message sent by an application is the same 
message that would have been sent had there been no connection break. In session 
based systems, that does not happen. Instead, considerable overhead is first taken up in 
re-establishing a session. Once the session is re-established message transfer re- 
commences, although re-commencing the message transfer might well involve re- 

15 transmitting, huge portions of previously transmitted message data — yet more 
unproductive data transfer. 

In MobileMQ, reliability (i.e. being able to guarantee that a message has been received) is 
achieved without recourse to high overhead session based protocols. Instead, we require 

20 receipt at the sending device of an acknowledgement that an individual message has been 
received and properly processed at the receiving device before allowing another message 
to be sent This 'message level' reliability is much more data efficient since it requires 
minimal overhead in re-starting communication if a connection is lost, unlike session 
based systems. This is a critical advantage, especially in wireless networks, where lost 

25 connections are not infrequent 

Authentication is, in the prior art, achieved with high data transfer overhead at the start 
of a session. Because the MobileMQ MOM is session independent, it instead provides 
for authentication of each message: 'message level' authentication. This may be 
30 combined with session level authentication, based on session numbers that increment 
whenever a device is rebooted. 
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MobileMQ when combined with Transcend Mail is a comprehensive and effective 
sotuuon to the twin problems of efficienuy handjing terminal resource and connection 
constra ints, as ^hQ^mJaJEigute _3. 



Fxgure 4 shows how the combined design allows session independent features provide 
by the MOM mat would normally be provided by a session based system ,o be deployed 
m a manner that is & for the purpose of resource constrained ternrinila, such aa smart 
phones. These features include: 

(a) reliability of message delivery; 
10 (b) sender authentication; 

(c) message security; 

(d) data rate flow control; 

(e) packet routing. 
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Hkewtse, it shows how the combined design allows features designed to be fit for the 
purpose of a distributed client to also address connection constraints. The main feature 
is the use of Wenf based data, and because of this gains the character of being session- 
independent 



3. Core Design Principles in More Depth 
3.1 Distributed client 

The purpose of the distributed client is to allow a mobile device with limited processing 
capaaty, power, and connectivity, to enjoy the functionality of foil-featured client access 
to a server environment using minimum resources on the mobile device by distributing 
some of the functionality normally associated with the client onto the server side which 

is not so resource constrained. The client applications are PUvl (calendar, address book 

etc.) and messaging (e-mail, MMS, fax, SMS etc). 

In effect, we have a split client-server application that collectively acts as the client in a 
larger client-server application. A typical configuration is to install software on a mobile 
devtce such as a smart phone (the small client) and corresponding software on a server 
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device (the small server). These two pieces of software commu n icate with one another - 
normally over high latency, low bandwidth, metered wireless connectivity such as GPRS 
or UMTS, via a MOM, such as MobileMQ. The small client and small server collectively 
act as a client (the "large client" or "distributed client") in a traditional client-server 
5 environment. The large client then communicates with the relevant server such as 
Microsoft Exchange (the large server) as normal. Thus, the large server is only aware that 
it is communicating with the large client. The large client appears to the large server like 
any other client with which it normally communicates and the distributed nature of the 
large client is invisible to the large server. (In a typical configuration, it is assumed that 
10 the small server will reside on or near the same device where the large server resides.) 
Figure 5 schematically illustrates this. 

Functions wi thin the distributed client are split between the small server and the small 
client. This split has been optimised to take advantage of the "smart" nature of the 
15 mobile device, while limiting the impact on that device's limited resources. 

Thus, the small client residing on the mobile device (i.e. Transcend Mail, in this case 
working in conjunction with the local e-mail application) generally acts as the user 
interface for the mobile user, acts as a local data store, and undertakes certain data 
20 processing tasks locally. Among others, the small client undertakes the following 
functions: 

• Displays a list of emails in the mobile in-box 

• Acts as a viewer for the body of email text 

o Accepts user requests to forward, create, or reply to email 
25 • Accepts user input for new email text 

• In response to user input, releases email from mobile device memory only (a Release 
action) 

• In response to user input, releases email from mobile device memory and generates a 
notice to release lie same email from the large server (a Delete request) 

30 • Accepts end user input of logon password for the large server and passes this to the 
small server (see below for description of "distributed logon') 
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• Monies the local data store for changes to that data (such as new, modified or 
deleted entries), creates an event detailing the changes, and sends these to the small 



serv er. 
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Recedes cents fiom the small server, and uses the det^s^anged data to update 
the local data store. 

Eouivarent or analogous PIM and non- e-mail firncrionaUty would be Wiled where ore 
small diem rrandles/mregrares ro PIM and nou e-mail (e.g. orher lands of messaging, 
functions. 6 

Similarly, the small server resides on other media (typically a LAN connected to the large 
server) and communicates with the mobile device via a data network connection that 
traverses wireless infrastructure (e.g. GPRS) and generally acts as the direct interface to 
the large server (such as Microsoft Exchange) and undertakes many data processing tasks 
normally associated with the large client Among others, the small server undertakes the 
following functions: 

• Completes construction of emails requested by the mobile user in accordance with 
the large server API, taking components received from the small client, the small 
server, and the large server as necessary 

• Takes emails from the large server and splits tiese into component parts, sending 
only those parts deemed strictly necessary to the small client 

• Responds to requests from the small client to deliver additional email content (e.g., 
additional text of long emails and/or attachments) 

• Takes logon password data (supplied by the end user via the small client) and saves 
tins m local memory, thus enabling extended logon to the large server (see below for 
description of distributed logon) 

- Monitors the local data store at the large server for changes to that data (such as new 
modified, or deleted entries), creates an event detailing the changes, and sends these 
to the small client 

• Receives events from tie small client, and uses *e details of changed data to process 
updates to the local data store at the large server. 
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Equivalent or analogous PIM and non- e-mail functionality would be handled where the 
small client handles /integrates to PIM and non e-mail (e.g. other kinds of messaging) 
functions. 



5 One consequence of this approach is that mail on a large server cannot be said to be 
'forwarded' or 'redirected' to a device in the manner of a conventional push e-mail 
system: instead the device (where the small client resides) together with the small server 
is simply another client to the mail server (and that client is also not a simple wireless 
device client as well). 

10 

The Transcend Mail small server and the small client communicate with one another via 
the MobileMQ MOM. As noted above, this enables the unusual feature of the small 
server and small client (which together constitute the large client in a distributed client 
server system) to operate asynchronously of one another. 

15 

There are various permutations of the small client: for example, as shown in Figure 6, 
the small client could be implemented as a terminal-side component, that either includes 
* or communicates with a client side MOM; the Small Server can then be implemented as a 
server-side component, that either includes or communicates with a server side MOM. 

20 

Figure 7 shows how the Small Client can include a program - e.g. an e-mail application, 
plus plug-in linking it to the terminal-side component. 

Figure 8 shows that the Small Client can also exclude the program, e.g. a contacts 
25 program. The terminal side component then communicates with the contacts program 
via the contacts database (with event triggers from that database being sent to the 
terminal side component). Figure 9 shows how this is conceptually equivalent to a 
middleware architecture. 

30 3.2 Distributed logon 

The distributed client splits the logon function between the small client and the small 
server. The small client obtains the user password from end user input. Upon receipt of 
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^password inpu, the small ^ sends ^ ^ w ^ ^ 

retains *. a» .ocai* ta memoiy> ^ ^ ^ ^ ^ ^ ^ ^ 



Hence, TranscencLMaiL acts as the wire1p« iv»«™„„i 

as me wireless terminal user'-s-agenfon the server- it cach^- 

Tins - a b, in securitv over other mail r^irecoon methods ^ 

to log 00 as a super-user which can access all email accounts 

10 

tlTfcT 28 ' ^ diSDlbUda8 1,16 iOg0n " *- ^ 18 *- * *- 

chent „ continue communication * the iarge server without agonal 

II ^ ( T aSSOCkKd ** — ^ diere is an interruption in 

us of the mobde device (which ma y have its own secufitv protocol) ,o serve as a 

ir d r ,aige setvet iogon « w * °~ - — — - - 

paa^orti tnformanon it becomes possible to rephcate logons Co the latge setvet baaeti 
on the assumptton that contto, of the mobiie tievice serves as a kind of substitu* foe 
logon tnformanon. This aUows me oisttibuteC dien. to acceas tire Urge setvet after an 
tntettupnon in service without prompting the uset for agonal password data This 
Ptoses advantage bv Iedllcing data ^ ^.^ ^ ^ ^ 

speeds up end uset access to the large server, particular!, on uaobile device, with anuU 
keyboards that are inconvemen, for entering password data. 

25 3 J Remote Message Construction 

Transcend Mai, also minimises use of wirdess transmission bv enapiovhtg a method of 
counting messages rem OK lv. When the disputed chent "retrieves" messages ftom ' 
tire large server, some of this data is oueued at me smaU server and the smaH server men 
determines how much of this da* is sent to me small client The specific amount of oata 
»0 sent to tiae smali cfient can be in flue nee d hv en d user configuration and bv sped 
request For e*am pl e, the end user can sped* a maximum number of hues of email « 
are dehvered ,0 the smail dien, and the end user can then reuues, that the sural server 
. send addtuohai text and/or attachments Remote message construction comes into p„ 7 
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when the end user directs an action such as replying to or forwarding an email. When 
forwarding an email with an unmodified attachment, the small server is able to construct 
the bulk of the email message locally without the need for fall transmission from the 
small client. The queued message simply references the relevant unmodified data held on 
5 the large server (in this example, an attachment). In effect, the small client is only 
required to transmit that part of the message that has been modified by the user at the 
small client device. The same principal applies to email replies. The small client does not 
need to transmit the entire body of the original message — the small server constructs the 
total reply by taking new text transmitted from the small client to the small server and 

10 combining this with the original email text - already known to the small server since it is 
stored on the large server. In effect, the small client has issued an instruction that results 
in the small server constructing the total message taking parts from both the small client 
and the large server. Avoiding unnecessary key input is valuable for a small keyboard 
smartphone. These are both methods for dramatically reducing the amount of data 

15 traffic between the small client and the small server. 

3.4 Tidy process 

Transcend Mail also helps to conserve memory on the mobile device using an automated 
memory "tidying" function. The small client monitors use of non-volatile memory on the 

20 mobile device. When non-volatile memory in use exceeds a trigger amount (for example, 
80% of memory capacity in use) then it automatically starts to "tidy" the local data 
related to email information on the device. This consists of selecting certain emails which 
have not been accessed locally for a longer period of time and releasing from local 
memory much of the data associated with these emails (for example, attachments and 

25 message text), whilst retaining the email header information in local memory. The data 
released from local memory is selected using pre-set criteria such as age of the relevant 
email message (oldest first) or history of access by the user to this email; email messages 
not accessed for long periods of time are removed from local memory before newer or 
recendy accessed email messages. 

30 

Message data is not released from memory if the relevant message is marked as unread, 
open for user viewing or action, or there is a pending action related to the email 
requesting additional data from the large server. 
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This removal process continues until the small client detects that non-volatile memory in 



The emaiLdata-is not "deleted" as the large server retains all email data and ffieamair 
client retains email header data. 
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The removed data can be replaced in local memory by downloading it once again from 
the server to the mobile device on user request (a ^Retrieve' action). The user is clearly 
warned before such a Retrieve takes place. This allows the user an opportunity to decide 
whether or not Retrieving the message data is cost effective. 

The tidy function also includes safety mechanisms that handle the circumstance where a 
particularly large email or attachment might push the mobile device beyond the trigger 
point for tidying without an opportunity to review the downloaded. In other words the 
design is meant to avoid a circumstance where the mobile device might remove email 
data before it is read In this circumstance, the system temporarily adjusts the trigger level 
and the safe level of memory use to allow the end user an opportunity to review the large 
in-bound email. 

20 3.5 Converted Attachment download option 

A perennial difficulty in mobile devices that share replicated data with a server is how the 
user can make best use of the limited memory and processing capacity on the mobile 
device. In mobile email applications, this problem has traditionally been addressed (in 
MS ActrveSync and others) through limiting the amount of email data that is shared with 
15 the mobile device. This limitation usually takes the form of replicating only limited 
number of days of email data, and limiting the s^e of the email data shared. One 
common method of limiting the amount of data replicated is to withhold email 
. attachments from replicating on the mobile device. Typically, the enduser may then 
request the attachment if they are willing to suffer the dehvery "time and memory 
0 overhead involved Other systems have produced a method of sending only a limited 
form of attached files to the user which can then be used on a simple viewer program 
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Transcend Mail provides the end-user with two options for downloading email 
attachments to the mobile .device. If the user wishes to download the attachment, he or 
she can choose between downloading: 

(1) a smaller version of the file translated from its original form (e.g., a text-only version 
5 of an MS Word or PDF file) intended -for viewing-only using a simple viewer 

program resident on the wireless terminal; or 

(2) the original unaltered attachment. 

In Transcend Mail these options are presented to the user at the same level of the menu 
hierarchy. 

10 

3.6 One-touch Release 

Problems arise as a conventional mobile device begins to be clogged with older emails. 
Often when the user attempts to "delete" these emails from the mobile device, they are 
then also deleted from the server at the next synchronisation. This may fly directly in the 
15 face of the user's desire — who may simply wish to free up memory on the mobile device, 
and yet preserve the email on the server. In order to accommodate this, some 
synchronisation systems give the end user the option either: 

(1) to delete an email entirely on both mobile device and server (which we call a 
"Delete" instruction), or 
20 (2) to delete only the copy of the email that is resident on the mobile device — leaving the 
server unmodified (which we call a "Release" instruction) 

In Transcend .Mail, these options are presented at the same level in the menu hierarchy - 
other systems have either hidden these options within a series of different menu levels, 
25 or have dealt with this by asking the user each and every time a deletion is requested 
whether or not the end user actually wants a complete deletion or merely to clear local 
memory. Both solutions are not user-friendly, as they reduce flexibility for administering 
the mobile mailbox and require multiple key entries to accomplish. 

30 3.7 Session independence 

Data communication with mobile telecommunications devices using technology such as 
GPRS is made extremely difficult due to high latency, intermittent and interrupted 
coverage, and the cost of metered bandwidth. Traditional communications methods and 
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protocols are not well suited to this type of environment. For example, applications that 
require a network connection over a wireless link such as GPRS usually use a TCP 
connection M -tM^gbmLjL^^ 

algorithm was developed for. a wired and relatively low-latency connection WIT not 
"wireless friendly". In areas of poor coverage the available bandwidth- reduces and this is 
compounded by TCP which assumes the network is congested and "backs off*. The net 
result of this is that a TCP connection over a cellular wireless network is not an efficient 
transport. It results in a large overhead of re-sent packets leading to slow and costly data 
transfers. Further, protocols like TCP rely upon the concept of a communications 
"session" with a server. A session typically will expire if no traffic passes for a defined 
period of time (a time out). Establishing each new session requires use of additional data 
traffic and is also time consuming 

MobileMQ envisages a wireless optimised alternative to TCP using only raw UDP packet 
transfers. MobileMQ delivers UDP based messages between (1) a mobile device using a 
wireless network and (2) a server in communication with that device (whether or not 
directly connected to the wireless network), so as to minimise wasted data traffic as a 
result of the high latency intermittent connectivity. MobileMQ focuses upon providing a 
high level of resilience in the message transmission process, effectively guaranteeing 
20 message, delivery. 

This is accomplished by employing a system for managing data communications that 
does not rely upon the traditional concept of a "session" - it is "session independent". In 
addition, the invention provides a method of guaranteeing that messages are properly 
delivered both to the destination, device and to the destination application, while 
ntinimisingthe amount of data traffic transmitted. This has the added benefit of assuring 
a high degree of resilience with a minimum of data traffic. 

MobileMQ is distributed in that it resides on both a sending device and receiving device, 
30 typically facilitating message traffic from other systems on the same hardware platforms. ' 

The sending device takes a Message - the core transmission unit - from the sending 
application (for example, an email program). Each Message is restricted to a maximum 
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size intended to optimise use of data traffic. When a sending application asks the system 
to send a Message, the system first persists (stores) the Message in local non-volatile 
memory at the sending device. This assures Message survival even if the sending device 
suffers a reset The Message is then compressed and optionally encrypted. 

5 

The Message is then segmented for transmission. Each each segment is positioned in a 
UDP packet with the intention that each packet does not exceed a relatively short byte 
length, which is related to the underlying transport protocol of the low bandwidth high 
latency network. In a typical implementation in a GPRS environment, the UDP packet 
10 length might be restricted to 1500 bytes as 1500 bytes is the typical maximum payload in 
a GPRS packet. Otherwise if a UDP packet were to occupy, say, 2 GPRS fragments, 
then a failure of one GPRS packet would mean that both GPRS packets would have to 
be re-sent. MobileMQ avoids this by scaling the message to match that of the bearer 
packet. 

15 

3.8 Flow Control 

Both segment size and transmission rate are controlled by a flow control system that 
analyses traffic to and from the sending device and strikes a balance between 
transmission speed and total number of bits transmitted in an effort to keep transmission 

20 cost-effective! UDP packets can be received in any order by the receiving device, and the 
receiving device transmits a packet acknowledgement following receipt of each packet. 
Where the sen ding device fails to receive a packet acknowledgement for a packet, the 
flow-control system delays packet retransmission until a reasonable period has elapsed. 
The precise length of the delay depends upon network response times observed by the 

25 flow control system at the sending device. The delay period and packet size are both 
continuously recalculated based on changes in observed return times. If a packet 
acknowledgement is received within a predefined time, the flow control progressively 
increases the data rate until it peaks. 

30 The flow control system also serves as a replacement for the normal concepts of 
"session" and "timeout" often used in data transmission devices. If one of the 
communicating devices suffers a significant connectivity failure (which could arise, for 
example, due to moving out of range of a wireless base station or moving between 
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roamtng networks) the flow control mechanism interpret mis as increasingly slow 
network response, and steps down transmission rates accordingly. If the service outage 
co^es^eJWcontroW 



r— ^twccii retries .1 fie net 

effect rs that transmission efforts come - almost - to a complete stop until the sending 
5 devtce starts to receive return traffic from the receiving device. As more reply packets 
make their way back from the receiving device to the sending device the pxocess 
reverses: the flow control system starts to "wake up" and becomes more adventurous in 
its wflhngness to transmit packets. As the connection becomes more solidly re- 
estabhshed, the transmission rate once again increases until it reaches a reasonably ideal 
10 level - balancing overall speed with the need strictly to limit packet loss (as lost packets 
may stnl mcur network transmission charges). Thus MobileMQ does not rely upon the 
concept of "session" and does not recognise the concept of a "timeout". 

Following receipt of all packets that comprise a Message, the receiving device transmits a 
15 bnef acknowledgement that the entire Message has been received. Once this Message 
acknowledgement reaches the sending device, the sending device will not attempt any 
further resends of packets that made up the Message - even if individual packet 
acknowledgements have not been sent to or received by the sending device. This is 
primarily intended to restrict the amount of data traffic. The Message delivery sequence 
20 is not yet complete. 

After transmitting the Message received acknowledgement, the receiving device then 
passes the Message to the relevant destination application (such as an email program) 
The receiving device then awaits a signal from the destination application that the 
15 relevant Message has been received and processed in accordance with whatever rule set is 
employed by the receiving application. The intention is that the receiving application 
processes the received Message so that it will survive a breakdown in the receiving device 
- such as a system reset. Once the receiving application is satisfied that it has received 
the Message irretrievably from MobileMQ, the receiving application then responds with 
final confirmation that the application has "consumed" the Message. This final 
confirmation from the receiving application triggers the receiving device side of 
MobileMQ to send a brief "Message Consumed" acknowledgement to the sending 
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device. 
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Once the sending device receives the "Message Consumed" acknowledgement, it 
forwards this information to the sending application and then prepares to transmit the 
next available Message from the sending application. In this way, MobileMQ guarantees 
5 delivery of the entire Message before accepting any additional Message traffic from a 
sending application. 

MobileMQ is able to process Messages from multiple applications simultaneously, but 
will not process more than one Message from the same application simultaneously. 

' 10 

3.9 Event based data replication 

Synchronisation between servers and mobile devices traditionally takes place using 
relatively high bandwidth, low latency, un-metered connectivity (e.g., USB or IR). As a 
result, synchronisation systems often employ a methodology that transmits large amount 

15 of data and is not very robust when data is lost in transmission or the underlying 
transmission is interrupted. For example, server based dataset synchronisation typically 
requires all connected devices to download their entire datasets (e.g. all e-mails, all 
contacts etc) to the server over a single session, which can then perform a comparison 
against its master copy of the last fully synchronised dataset in order to update the master 

20 and hence all other datasets. This approach is unattractive for synchronising wireless 
devices because of the power drain it imposes, the potentially long connection time and 
costly data transfer. 

In Transcend Mail, instead of a wireless device downloading its entire dataset, it records 
25 only dataset changes (or new 'events') into log (preferably, but not necessarily, time 
sequential) and sends a log of these events to the server when connected to it. An event 
gives enough detail to enable data replication to take place without the need for a 
synchronisation engine; data replication (a.s opposed to true synchronisation) is more 
simply achieved by sending events rather than a complete dataset (or sub-sets of a 
30 dataset) of stored data for synchronisation by a synchronisation engine at the small 
server. 
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Whenever a change „ . record on 4c deiice „ made ^ ^ ^ fc ^ ^ d ^ 
fan the device; old marl is deleted; a new contaet created etc), an enay defining jus, this 

event or change is s t ored on the d e t d cednAe-rim.^^^^M, ctuu L g 1» alt ,red 

until a connection* present, at which point the logconmnts vwrntm*. server which 
updates to mastet copy of the relevant dataaets. For eaample, the event might be 'delete 
record no. *. or delete field y in record V. This is enough information for the recipient 
to rephcate the change that occurred a. the sender that generated the 



event. 
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There . no need for the device to pass mrough an entire dataset to determine records 
that have changed or to ensure maintenance of a single session whtot the entire damet is 
transmitted and received. Any changes to the datasets on the server (e.g. receipt of new 
»■* «*o stored as an event .og and me log sent to me wireless device uaing 
MohtleMQ. Beeauae only rdatively smaU even, logs axe generated and exchanged, me 
CPU and data transfer overhead are far smaller than conventional Sync mechanisms.' 

Hence, when data subject to replication is entered, modified, or deleted (on either the 
large server or the small client) me sending device creates and logs an "evenf ■ on the 
sending device. 

He event is sent as one or more messages to the receiving device; messages are sen. 
usmg TOP packet transfer and not me more conventional TCP. Whilst TCP provides a 
reliable connexion and is current!, a focus of commerdal activhy, i. is no. (as explained 
above) an efficient transport for wireless because of to pronounced back-off during 
times of perceived network congestion, which arises not infrequent!, when wireless 
coverage is poor, leading no a large overhead of re-sen. packets, leading to slow and 
costly data transfers. For efficiency, UDP is used (see above) with UDP packet aiae 
restated to 1400 byte, - just under me transmission packet size available in GPRS. 

The receiving device passes individual messages defining me Even, .o me relevant 
delation application (such as an email program). The sending device then awato a 
s^nal from the destination application mat the relevant messagefs] defining the Event 
, has been received and processed in accordance with wharever rule se. is employed by me 
recetvmg application. The Intention is that the receiving application processes the 
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received message[s] so that it will survive a breakdown in the receiving device - such as a 
system reset Once the receiving application is satisfied that it has received the message[s] 
irretrievably, the receiving application then responds with final confirmation that, the 
application has "consumed" the messages. This final confirmation firom the receiving 
5 * application triggers the receiving device side to send a brief '"Message Consumed" 
acknowledgement to the sending device. 

Once the sending device receives the "Message Consumed" acknowledgement, it repeats 
the process for all messages defining an Event until it has been safely received and 
10 'consumed' at the receiving device. It then concludes the "event" process by deleting 
[event instruction information?] from sending device memory. It repeats this process for 
all other events in the Event log or queue. 

In this way, Transcend Mail guarantees delivery of the entire message before accepting 
15 any additional message traffic from a sending application. Processing messages from 
multiple applications simultaneously is possible, but not processing more than one 
message from the same application simultaneously. 

An entire Event can therefore be sent reliably over a wireless link, despite the use of 
20 unreliable UDP. 

3.10 A /B/X Flags 

The system also guards against duplicate Message transmission by coding each Message 
with a flag with three state options: A, B, or X. In normal operation, each Message [from 

25 an application] is transmitted by the sending device with alternating A or B flags. As the 
receiving device starts to receive the Message, it writes the A or B flag to local memory. 
Upon receiving the complete Message from the sending device and the consumed signal 
from the destination application, the receiving device writes to local memory the flag 
identity of the Message just processed before transmitting the Message done / Message 

30 consumed acknowledgement. If the receiving device resets after sending a Message 
done/consumed acknowledgement signal but before an acknowledgment is received 
back, then it will not know if the message consumed was properly received or not. But if 
it flags the sequence of acknowledgments relating to a given message with one type of 
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flag, then it knows that any acknowledgement back must match the flag in order to be 
relevant An acknowledgement with a different flag must relate to the next message and 
-iie0c_e_sh.o.uld_aotLb e_actione d, _ . 



A flag of X signals the receiving device to ignore the flag and no flag is written to 
recemng device memory. The intention is for a transmitting application to use the X flag 
if the application is unconcerned about the risk of duplicate message transmission. 

3.11 Client Device Addressing and Network Update 

Sending a data transmission to a mobile device on many current mobile data networks 
(such as those using GPRS) is made difficult because the mobile device has no fixed IP 
address. Instead, when the mobile device connects to a network (either the home 
network or a roaming network) the network operator dynamically allocates an IP address 
to the device. Further, this dynamically allocated address is usually a private IP address 
and not directly usable on the public Internet Instead, data traffic from the device is 
routed by the network operator to a Network Address Translator (NAT) and the NAT 
maps the private IP address to a public IP address and ephemeral port numbers drawn 
from a very limited list of public addresses (sometimes just two) and a larger block of 
ephemeral port numbers (several thousands usually) available for use by the network 
operator. 
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Thus even if a mobile device retains the same dynamically allocated IP address and 
ephemeral port number for a longer period -(e*. many hours), it might make use of 
multxple "public" IP addresses and ephemeral port numbers allocated by the network 
operator. Further, akhough the mobile device.is aware of the private IP address allocated 
to it by the network operator it will have no record of the public IP address and 
ephemeral port number allocated by the NAT. From the perspective of anyone 
communicating with the mobile device, they will "see" only the public IP address and 
ephemeral port number allocated by the NAT This creates a significant challenge to 
anyone who wishes to originate and send a data message for transmission to a mobile 
device that uses such a network because there is no guarantee mat the last known public 
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IP address and ephemeral port number associated with a given device will be valid for 
more than a few minutes. 

MobileMQ provides the small server with network address data on a regular basis to 
5 enable routine trans mi ssions of messages from the small server to the mobile device. 
Examples of implementations would include enabling an office email server to send 
email traffic to a mobile user without intervention by the mobile user. 

The method involves sending an extremely short message (a "Network Update 5 ) from the 
10 mobile device to the small server upon the occurrence of any of the following events: 

• when the mobile device is first switched on and acquires an address from a mobile 
network operator; 

• when the mobile device receives a new address from a network operator (perhaps as 
a result of moving the device from home network coverage to a roaming network or 

1 5 between roaming networks) 

• whether or not a new address is allocated to the mobile device, on a regular timed 
basis in an effort to obtain a new public address arid ephemeral port number that 
may have been allocated by an intervening NAT and advise this new public address 
and ephemeral port number to the small server 

20 

Upon receipt of the short Network Update message, the small server notes the 
originating IP address and ephemeral port number of the packet (which will be the 
assigned public IP address and ephemeral port number from the NAT, assuming that the 
interested party is not directly connected to the same private IP network) and enters this 
25 information in a reverse lookup table. 

The Network Update messages are intentionally short due to the assumption that data 
traffic is charged on a metered basis. A typical implementation might involve only 17 
bytes of data transmitted by the mobile device and 5 bytes returned in each Network 
30 Update message cycle (assuming no packet loss). 

Each of these message cycles serves to confirm: 

(1) the continuing validity of the public network address and 
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(2) that the mobile device is available to receive traffic. 
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the small-elient-on themobile device by. using the most recent address for the devicl 
found tn the reverse lookup table, assuming that the allocated public IP address and 
ephemeral port number has not been reallocated from the time of the Network Update 
message. Hence, receipt at the small server of the Network Update message from a 
device acts as the trigger to start sending any events queued in the event log (see Event 
Based Data Replication section 3.9). The system can be configured so that only events 
present in the log at the time the Network Update is received are sent; any later events 
have to wait until the next Network Update is received. This differs from continuous 
push e-mail. 

The entry in the reverse lookup table is also timed, and if more than a certain amount of 
«me has elapsed the small server assumes that it is no longer possible to transmit 
messages to the small client until a new Network Update message is received. In this 
circumstance, outbound messages from the small server are held in a queue until a new - 
Network Update message is received. The time is set at substantially less than the normal 
interval used by the NAT to re-allocate public IP addresses to mobile devices (eg 5 
minutes if the NAT re-allocation interval is 20 minutes). The system can dynamically 
adjust the time so that when there is very high network useage, associated with much 
shorter NAT re-allocation intervals, the time can be shortened. 

Taken together, this means that the small server and the small client are able to establish 
a time window during which it should be possible for the small server to send traffic to 
the small client The window starts at the time of a Network Update message, and ends 
when the pre-programmed idle time expires. For example, if Network Update messages 
are sent by the small client every.60 minutes and the idle timeout is set to 10 minutes, 
this results in 10 minute communication windows that recur in periods of not less than 
60 minutes. By increasing the frequency of Network Update messages the small client 
i also create more or less continual communication transmission opportunities for the 



small server. 
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3.12 Security 

Existing security methods to assure secure end-to-end communication over non-secure 
data communication infrastructure (such as SSL) are not well suited to a wireless data 
5 communications environment due to a number of factors, including high processor 
overhead, high bandwidth overhead, high latency, and dynamic allocation of addressing 
information to the mobile device. 

MobileMQ provides secure end-to-end messaging between a mobile device and a server 
10 using a cryptographic implementation designed specifically for a mobile 
telecommunications device. 

The process begins when the system is first installed on the mobile telecommunications 
device. The mobile device (for example, a mobile email reader connected to wireless 
15 network) and the server (for example, a corporate email server connected to fixed line 
Internet service) are both loaded with shared secret information. In order to secure 
messages between them, the sending device (either the mobile telecommunications 
device or the serve) first calculates a message key by using a hash function to calculate a 
hash from the following inputs: 
20 • a code unique to the relevant mobile device, for example the IMEI code of a GSM 
telephone handset (if the mobile device is the sending device it uses its own unique 
code and if the server is the sending device it uses the unique code of the intended 
. recipient device) 
• the shared secret, and 
25 • additional data relating to (but not necessarily unique to) each message (i.e., the 
incrementing message number, application/port number, and session number) that 
can be calculated independendy by both the sending and the receiving devices 

This key is then used in a symmetric cryptographic algorithm to encrypt the message. 
30 Thus each message is encrypted using a key sequence that is mathematically related to the 
individual mobile device identity code, the shared secret installed on the mobile device 
and server, and additional data that can be independendy derived by both sending and 
receiving device that is mathematically related to each message. 
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To assure authenticity and integrity of the encrypted message, the sending device then 
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where the inputs are the message itself and the keythat was used to.encrypt the meTsigeT 
The resulting MAC is then appended to the encrypted message. 

The receiving device calculates the first hash function (the key) for the relevant message 
(based upon its knowledge of the mobile device unique code number, the shared secret, 
and the additional traffic data), and uses this key to decrypt the message. Finally, the 
receiving device takes the decrypted message and the key and uses these to calculate the 
second hash value for comparison with the MAC appended to the message. If the 
second hash value is identical to the MAC received with the message, then it is assumed 
that the message is authentic and unaltered. If, on the other hand, the second hash value 
calculated by the receiving device does not match the MAC received with the message, 
then the receiving device issues a challenge to the sending device in an effort to re- 
establish secure communication. Once security is established, this then triggers re- 
transmission of the message. Thus the authentication system serves in a back-up role to 
assure the data integrity of the message - any bit errors in transmission would result in 
failure of the MAC, a security challenge, and message retransmission. 

In addition to assuring confidentiality, authenticity, and integrity of messages themselves, 
the security system also serves to reduce the cost and performance impact to the mobile' 
device user if third parties attempt to masquerade as the legitimate mobile device user. 
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The small server keeps a reverse lookup table with the most recently reported address 
(and ephemeral port number) assigned to the mobile device. (See description of Network 
Update at section 3.11) The small server operates on the assumption that all in-bound 
, data packets from the mobile device should come from the address and pprt number that 
matches the currently-valid address and port number for the device listed in the small 
30 server reverse lookup table. 

If data is received that purports to come from the same mobile device but has a new 
return address (and/or new ephemeral port number), the small server issues a security 
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challenge to the device at the new address using the same cryptographic mechanism 
outlined above. If the new address returns the correct answer to the challenge, then the 
small server continues to process in-bound traffic from the new address and also updates 
the reverse lookup table with the new address. This would normally happen only if the 
5 mobile device is assigned a new address or ephemeral port number in such a manner that 
the mobile device is not aware of the change (e.g., if a network operator NAT box made 
such an assignment), as changes notified to the mobile device already trigger a Network 
Update message. (See description of Network Update at section 3.11.) 

10 If, on the other hand, the new address is unable to respond correctly to the security 
challenge then the small server does not update the reverse lookup table and simply 
ignores the data received from the new address; (This could happen if, for example, a 
malicious third party attempted to interrupt communication to the legitimate mobile 
device by sending spoof data traffic to the small server.) Communication with the 

15 legitimate device (at the old address with the old ephemeral port number) continues 
uninterrupted and without the need to re-establish security using an additional challenge 
to the old address. No unwanted data traffic is generated from the small server to the 
small client; this is important since, with many GPRS and UMTS tariffs, the users' costs 
depend on the amount of data traffic received, so being able to bar denial of service 

20 attacks at the small server is very valuable. 

This system will have a significant cost and performance benefits to the legitimate user 
because security challenges and responses use relatively large amounts of both processing 
time and data transfer. 

25 

3.13, Terminal application lock 

Mobile communications terminals (such as "smart" phones using GRPS) present certain 
security risks tq device users and the organisations that act as their primary 
communications server (such as an employer-operated business email server). Loss of the 
30 device could result in unauthorised access to communications applications (such as an 
email client application), which could then have negative consequences for both the end- 
user and the organisation providing background server capability: At the moment this 
security risk is addressed by various systems (1) to lock local access to the mobile device 
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itself- normally at the request of the end user, (2) relying upon mobile operators to deny 
communications with the device, or (3) deny remote access to the main communications 
..aerxer^e^^ 

deprive-the-user-of access- to other applications resident on the device. Thel^ond 
method relies upon swift and appropriate implementation of blocking instructions by the 
mobxle operator. It is further limited in circumstances (such as a GSM network using 
SIM cards) where authentication with the wireless network is undertaken independently 
from the mobile device - the person who possesses the device may still be able to access 
locally resident data. The third method is flawed as it only blocks access to the 
organisation server, and does not disable access to data locally resident on the mobile 
device. 



Transcend Mail provides a system to "lock" operation of the entire communications 
application under prescribed circumstances to protect both the end-user and the 
15 organisation responsible for a corresponding communications server, without the need 
for intervention by the wireless network operator that normally carries traffic from the 
mobile device. 
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Access to the relevant communications application on the mobile device can only 
proceed after the end-user has entered the appropriate locking code in the mobile device. 
The system can specify a minimum code length, but otherwise allows the end-user to 
change the locking code. The organisation administrator (who also administers the 
Transcend Mail server) can also change the lock code on a remote basis, thus enabling a 
code reset if the end-user forgets the code or the device is lost or stolen. This protects e- 
mail resident on the device and also the mail server, but under the control of the 
organisation, rather than an end-user or network operator - a critical difference. 

In its locked state, the application. lock can be de-activated by entering the appropriate 
lock code into the mobile device. 

If the lock code is stored locally on the mobile device, it can be stored using a 
cryptographic hash value based on the following inputs: 

• a unique device ID for the mobile device (such as an IMEI code on a GSM handset) 
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• a secret key 

• the unlocking code 

This way, the lock cannot easily be circumvented by simply taking the hashed code value 
from one device and replacing the stored has value on another device. 

5 

After being unlocked, the application lock is then triggered by a number of different 
events, such as: 

• passage of time without accessing the application (a pre-defined idle time) 

• remote change of lock code by a system administrator 
10 • end-user requests application lock 

• mobile device or the relevant application is rebooted or restarted for any reason 

• a remote message directing the application to enter a locked state 

If the application is in a locked state, the end-user is unable to access local data and is 
15 also unable to access the remote server. 
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APPENDIX I 



"5 -ns« 

1 • Independent delivery of messages from different categories 

Description 

io ^LSEZXttttZ SMS zr^ to ensure - 

• New message channel 

• Additional Body text channel 

• Attachments channel 

15 ^SZ2^7&J&"Z£Z£ be partia " y - 

Analysis 

calendar, and is a comnK SStSSi f technique * ^ fr ° m U8ed by ^ or 
20 slnXppH^K 0118 tech "^ to expedite communications within a 

ESSES SS^5i=^ ^i" 9 3 *- e ™« not 

_ transfer of a large nJ^tiSS^Z^LS^S^ "* the back 9™n d 

25 message channel and Sm^S^^VS^^SI^ 5 transferred b V a Cerent 
shorter messages. Thus a smaller ^ifSSEi ! bandwidti ? Wlth a separate channel for 
a large email wuld could ^SuS^^tSS^^ ^ f 8r the transm '^ion of 
emails/this could mean that theVesmns J to 2 arge ema "- For extr emely large 
. completes delivery. This is m^osS wiS t j™" T™' ' S received before the lar 9e email 
30 queue emails irrespective of siT * contem P orar y ^ail systems, all of which 

KM *> a - -ay - one for each emai, - 

2. 'Magic' email addresses 

; Description 

?5 has e 2la2r er t0 be tranS,ated by the Server into r ^'ved emai. addresses. This now 

0 • xsr^z:r^~'sr 
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in exchange, and if a match is found, the name is resolved into that user's email 
address and delivered to them 
Note: this functionality is pending a change request. 

Analysis 

5 The use of a fixed string in place of an email address to have a meaning that depends on the 
content of a previous email is something that is probably new. 

The use of such a string effectively constitutes a 'command* to direct the server to complete 
the addressing of a new email, based on the content of some previous email, known to the 
Server In this case, the command is a 'reply to all", the 'content' is a list of email addresses 
10 in a previous email, and the 'previous email' is that to which the client is responding. Neither 
the list of addresses nor the email itself need reside on the client for this concept to work. All 
that is needed is a reference to the previous email (e.g. a header) in order for the client to 
have some sort of handle to it. 

It is common practice to permit the use of short (or 'friendly') names in place of email 
15 addresses that are resolved by a client or server prior to delivery to the recipient(s). However, 
this may be a new concept in the wireless, distributed client space. 

3. Enable/Disable 

Description 

The ability to disable local queuing without affecting queues at the remote other end. 
20 Analysis 

The purpose of this function is to allow a peer to temporarily suspend its subscription to 
synchronisation of events in one or both directions. This may be applied to one, more, or all 
channels. 

Examples of this include: 

25 • Suspension of contacts synchronisation by a user whilst local maintenance (e.g. 

deletion of unwanted items; local, cabled synchronisation with a PC) is earned out 
that would otherwise generate excessive traffic to keep the remote end in sync 
• Suspension of the service on a per-user basis, by an administrator to control costs or 
prevent abuse 

30 4. Scheduled queue additions. 

Description 

The ability to perform actions that will result in items being queued for transmission, without 
the need to transmit the item immediately. E.g. create an email when Vega is disabled. The. 
software will not attempt to send the message until Vega is re-enabled. 

35 Analysis 

This function is not new among email clients, both wired and wireless. However, it may be 
new when applied to the wireless, distributed client space. 
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Auto/Manual mode operation 

Description 



10 



The^rflftytg toggle between automatic and manual connection Sel \ 

Analysis 

predefined period «%X£££^ to '°P e ™9 ■ gate' for a 

and is almost certainly so in the wSesto^ G ° nCSp! !S prabab * nsw " 

6. In-line attachment replacement 

15 Description 

Analysis 

non-transmission of an ^^JinTstafeS *" emai ' ^ the r6aS ° n f ° r 

However, there are many reasons for non-transmission of attachments to wireless, distributed 
Some reasons may be elective: 
25 , size exceeds a size set by an administrator 

• User is not permitted to download attachments (e.g. for cost control reasons) 
Some may be circumstantial: 

• Attachment is not compatible with the terminal and cannot be converted by the server 

• Attachment is infected with a virus 

30 • Attachment has previously been deleted 

7. Remote attachment representation 

Description 
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Analysis 

Outwardly, this function is not new among email clients, both wired and wireless. However, 
there are aspects of this feature that warrant investigation. 

It is similar to the feature of some email clients that show a paperclip or other icon to indicate 
5 the presence of an attachment. In IMAP4 clients, the attachment may or may not be actually 
present. 

However, this feature may be new in the wireless, distributed client space - particularly if 
combined with an indication, by different icons or by local inclusion of explanatory body text, 
of the presence or otherwise of the attachment. 

10 8. Email recipient list truncation 

Description 

The representation of the number of additional recipients of an- email message without the 
need to transmit resolved email addresses for each recipient. 

Analysis 

15 This function is probably new, and almost certainly so in the wireless, distributed client space. 

The intention is that when the number of users in a distribution list exceeds a certain count 
(e.g. 10), the recipient of the mail is probably not interested in the actual individual users on 
the list. Hence, data volume may be reduced by not including the names and email 
addresses of other recipients in the email headers. Rather a simple piece of text (e.g. "38 
20 other recipients") is substituted. The full list of recipients could be downloaded on request. 

This special text would not affect the ability of the user to 'reply to all' since the actual email 
the server would still know actual addresses. 

9. Content hiding when security is invoked 
Description 

25 The ability to hide on-screen user data by use of an alternate view. This is used to hide a!! 
user data when the terminal enters a Password challenge' or 'Applocked' state. 

Analysis 

This function is probably not generally new, but may be so in the wireless, distributed client 
space. 

30 The purpose of the function is to hide privileged information until an authorised person 
completes the security challenge. This aims to protect against the theft of on-screen 
information. 

10. Intelligent user creation list * 

Description 

35 The ability to provide the administrator with a list of users who are suitable for Vega account 
creation. In reality this means going to Active directory, and sorting users according to which 
server they are on, and whether a Vega account already exists for that user. The resultant list 
(displayed in the 'New User 1 Ul) displays only the users that can have a Vega account. 
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Analysis 



«*IMU*-&u««I^^ 

5 11. Customised event fogs ~~ ~ 

Description 

■ S£2^pSSSSS5iS 1 ° f m ° re rem0,e Senrere ' ffltere ' « «*>< -I/ eveols 
Analysis 

10 EttSESttZS^SA'T-* " « Howler, 

12. File-level OEM customisation 

15 Description 

Analysis 

do since tt is contempt prSoe h mls?s£S d^Zs ' C ° mPe ' en ' pere ° n """"" 
13. 'intelligent' queuing 
25 Description 

So'me*^^ dueue . 

Analysis 

followed by Its Immediate de£T2i/l^ ' ",5 5 ueue c °ntalns a new contact 
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14. Retrieval cancellation prior to transmission 

Description 

The ability to cancel a retrieval request BEFORE the data transfer has begun. 
Analysis 

5 This is similar to the ability to remove an item from an Outbox, and may apply to email, 
contacts and agenda items. It is certainly not a new concept since many email and 
groupware clients provide this functionality. 

However, this technique applied wireless, distributed client/server systems may be new - 
particularly since the destination of the items in the 'outbox' is not a mail or groupware server, 
10 but another component in a distributed client. Only after transmission to the remote 
component distributed client do items truly enter an 'outbox' pending transmission to some 
further destination (e.g. on the internet). It is the initial transfer that is cancellable by this 
function. 

15. Poll and Push users 

15 Description 

The ability to create 'Poll 1 and Push 1 operation user accounts within a single organisation or 
installation. 

Analysis 

This function allows some users to operate in a true push mode, others in a strictly polled 
20 mode, and others in a mode that is 'effectively push* due to the frequency of polls. 

This concept is not new among general email clients - the choice of one user's preferences 
for email delivery does not usually have any effect on the choices made by users. 

However, 

• This function applies to Vega, which operates specifically in the wireless space. Such 
25 systems are usually 'all push' or 'all poll' as dictated by the design philosophy 

adopted by the system. 

• The terms 'push' and 'poll' apply to communications within the distributed client - not 
within the larger Client/Server model, which is always 'push'. 

Hence, there are novel concepts that merit investigation. 
30 16. Provisioning logic 
Description 

The ability to modify, negate or deny the handset provisioning process based upon 
information about the user selected account and connected handset. 

Analysis 

35 The purpose of this invention is to direct a provisioning user with a list of possible options that 
are open to him based on the circumstances presented by the status of existing accounts and 
the status of the connected handset. 
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JSl^-fi * ™* Mention is to the two 

them: * model and the for 9 ,n 3 breaking of the links between 

~— lioSS""^ ^^^^^se-Vega^^oe^noHiave 
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o If the handset is currently allocated to another user 

" a N ,roc C ati n on 9Urati0n * P ° SSib ' e: admin ^tor must remove the 
o If the handset is currently not provisioned: 

- The software is installed and a base synchronisation is performed 
• If the user account selected is permitted to use Vega and has a handset allocated ' 

o If the handset is currently allocated to the user 

- The handset software installation is repaired if necessary 
■ The handset is left unmodified if appropriate 

o If the handset is currently allocated to another user 

" aTocSion 9Urati ° n iS P ° SSib,e: an admi ™*ator must remove the - 
o If the handset is currently unprovisioned 

- The allocation is modified; the user's current handset is wiped 
• The software is installed and a base synchronisation is performed 
• If the user account selected is not permitted to user Vega 
o Further action for that user is not permitted 

17. Wipe handset 
Description 

Abilrty to send a command to a user's device that will result in the removal of all data from that 
Analysis 

This feature may be new. particular in the field of wireless, distributed clients. 
35 18. Data transfer timestamp 
Description 

S a " d d,SP,ay ° f the timSStam P of the ,ast time **» was sent or received from a user's 
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Analysis 

The purpose of this feature is to record the time and data of the last data transfer received 
from the remote component of the distributed client This provides the user with a confidence 
check that the system is working in the absence of any application data. 

5 Large elements of this feature may be reasonably apparent to a competent person. However, 
owing to the underlying unreliable nature of the transport, it is not possible to determine the 
exact time of the last transfer from terminal to server. However, since all communications in 
either direction result in at least a confirmation of some sorts in the other, recording the last 
incoming data provides proof that at least some outgoing data was received. 

10 19- Software installation 

Description 

The ability to install (and subsequently uninstall) software from a Symbian OS product 
WITHOUT using the standard (SIS file) method for software installation. 

Analysis 

15 The purpose of the Symbian SIS file is to ease installation in much the same way as is 
frequently achieved in other software environments through the likes of InstallShield and 
others. 

However, the connectivity platform used by SymbianOS devices no longer permits the 
automatic execution of SIS files, thus it is not possible for an administrator to instigate the 
20 installation of software without physically interacting with the device (i.e. pressing buttons, 
interacting with the Inbox, etc). 

The nature of this feature is to avoid the installation system altogether by copying files into 
certain folders such that on restarting the device, certain 'run-once 1 components are executed 
that complete the installation and configuration of the device. This permits per-device 
25 installations that would otherwise require complicated re-compilations of the SIS file. 

The only course of action required by the installer is to power-down the device before handing 
it over to the user. This guarantees that the installation sequence completes. 

20. Security updates in the field 

Description 

30 The ability of an administrator to update terminal security policies on user's terminals in the 
field (e.g. increasing the minimum number of digits or timeout period of the application lock). 

Analysis 

The purpose of this invention is to permit the administrator to remotely change certain security 
credentials of devices without requiring them to be re-provisioned or returned to him to 
35 implement the change. * 

Such changes may include: 

e A change in. the policy of the minimum strength of application lock code that a user is 
required to choose - this may force a change of code for some users 

• A scheduled change in the shared secret used by a device 
40 • A demand that a user change his logon password 
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ZL Poll/Push updates in-the-field 



Description 
Analysis 

iq An administrator may require changing the frequency of poiiing for certain users in response 

• Policy change regarding the types of expenditure permitted by certain users 

• To target particular users to change volume habits 

thlS inVentl '° n a " OW an administrator •» Change any or ail of the fo.lov.ng on a 
15 * Se 6 ^ the amount of background data 

• C ^°^Z^ active push- by 
. Change to or from true 'push' mode in which case no micro-polls are used 

t^zsss^s of th H e components ° f a d ~ 

the administrator is the sole pnViS SfiZ se^ngs. " 0 COntr0 ' ° Ver the above: 
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CLAIMS 

1. A data access, replication or communications system comprising a software 
application that is distributed across a terrninal-side component running on a terminal 
5 and a server-side component; 

in which the terminal-side component and the server-side component (3) together 
constitute a client to a server and (ii) collaborate by sending messages using a message 
queuing system over a network. 

10 2. The system of Cl aim 1 in which the message queuing system is message oriented 
middleware. 

3. The system of Claim 1 in which the terminal-side component insulates a terminal 
program from being affected if the connection over the network is broken by also 

15 queuing messages in readiness for the connection to be re-established, enabling the 
terminal program to proceed to its next task. 

4. The system of Claim 1 in which the server-side component insulates a server 
program from being affected if the connection over the network is broken by also 

20 queuing messages in readiness for the connection to be re-established, enabling the 
server program to proceed to its next task. 

5. The system of Claim 1 in which each message that is queued defines part or all of 
an event, in which an event describes a change to the data stored at either the t ermin al or 

25 server in enough detail to enable data replication to take place without the need for a 
synchronisation engine; data replication being achieved by sending events rather than a 
complete dataset (or sub-sets of a dataset) of stored data for synchronisation. ■ 

6. The system of Claim 5 in which the terminal-side component can create events 
30 and queue those events, itself and/or in the message queuing system, enabling the 

terminal-side component to proceed to its next task, even if the network connection is 
broken. 
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7. The system of Claim 5 in which the server-side component can create events and 
queue those events, itself and/or in the message queuing system, enabling the server-side 
_c_omp.onen^^ 



10 



8- The system of Claim 6 in which queued events persist in non-volatile memory 
even when the terminal is switched off. 

9. The system of Claim 7 in which queued events persist in non-volatile memory 
even when the server is switched off. 

10. The system of Claim 1 in which the terminal-side component and the server-side 
component collectively constitute middleware between a terminal program running on 
the wireless terminal and a server program running on the server. 

15 11. The system of Claim 6 in which messages that are queued on the terminal side 
are references to data held on the server. 

12. The system of Claim 10 in which a message queuing system on the terminal side 
-sulates the terminal program from being affected if the connection over the network is 
re-established by automatically causing the next message in a terminal-side queue to be 
sent 

13. The system of Claim 10 in which a message queuing, system on the server side 
insulates me server program from being affected if the connection over the network is 
re-estabhshed by automatically causing the next message in a server-side queue to be 



20 



25 



sent. 



30 



14. The system of Claim 1 in which the terminal-side component processes events 
from a terminal program, which is an e-mail or EM prografia. 

15. The system of Claim 1 in which the server-side component processes events 
from a server program, which is a mail server program. 
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16. The system of Claim 1 in which the terminal is a wireless terminal, such as a 
mobile telephone or smartphone. 

17. The system of C laim 1 in which the network is a wireless WAN network, such as 
5 a GPRS or UMTS network. 

18. The system of Claim 1 in which the server- side component stores a logon 
password sent from the terminal-side component and can use this logon to access a 
server program. 

10 

19. The system of Cl aim 1 in which the server-side component can assemble a 
message that the terminal-side component wishes to send by using data held on the 
server in order to avoid that data needing to be sent over the network from the terminal. 

15 20. The system of Claim 1 in which the terminal-side component monitors available 
memory on the terminal and automatically deletes data stored on the terminal that meets 
pre-defined criteria of age and/or use and/or size without affecting the corresponding 
data stored on the terminal. 

20 21. The system of Claim 20 in which a user option to delete data stored on the 
terminal without affecting the corresponding data stored on the server is displayed at the 
same level in a menu hierarchy displayed on the terminal as an option to delete data 
stored on the terminal together with the corresponding data stored on the server. 

25 22. The system of Claim 20 in which the data is message data and the terminal side 
component retains data that allows the message data to be re-supplied from the server if 
requested by a user. 

23. The system of Claim 20 in which data is not released from memory if the data is 
30 marked as unread, open for user viewing or action, or there is a pending action related to 
the data requesting additional data from the large server. 
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24. 



The system of Claim 1 in which * e terminal . side component 
document attachment to be sent to the tireless tetminal in either the original format „ 



a 
in 



the original format. 

25. 7k ^ of Claim 1 in which ^ teImmal , ide componeM ^ _ _ ^ 

(a) select a release option ,o delete a message stored on the terminal but not the 
copending message stored on ^ serv „ ^ ^ to ^ ^ a ^ ^ 

delete a message stored on the tetminal and also the corresponding message on the 
server, the release and delete options appearing at the same level in a menu hierarchy 
displayed on the terminal. 



a user to 



26. The system of Claim 1 in which the application enables the correct muting- of 
messages addressed to a terminal identified > by an ID by mapping that ID to the actual 

10 If address needed to reach the terminal. 

27. The system of Claim 26 in which the address is a dynamic IP address allocated by 
a NAT box. J 



20 28 The system of Claim 27 in which the application only miua KS a message transfer 
if there exists a valid mapping. 

29 The system of Claim 28 in which a mapping is refreshed whenever a specific kind 
of small, dedicated message is received from the terminal 

25 

30. The system of Claim 1 in which the terminal-side component allows a server 
administrator to lock an application on the terminal without affecting other applications 
on the terminal. 

30 31. The system of Claim 1 in which the terminal component sends a challenge to any 
third party suspected of attempting a denial of service attack on the terminal and that 
denxal of service attack does not then lead to any additional data traffic to the terminal 
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32. 



The system of Claim 1 in which the application comprises a distributed 
application platform that makes calls to a distributed communications platform. 

33. The system of Claim 32 in which the communications platform enables delivery 
of a message over the network to be reliable, even if an unreliable transport protocol is 
used, in which the platform operates in a session independent manner 



1/7 



Terminal resource 
constraints 




Terminal resource constraints are met in essence through the combination of a 
'distributed client collaborating across a message queuing system, such as a MOM 

Figure 1 




Connection constraints 



Connection constraints are met in essence through the combination of a message 
queuing system, such as a MOM, used by a platform operating in a 'session independent' 
manner 



Figure 2 
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Figure 3 
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Session 
Independence 



Connection constraints 



The Transcend Mail and MobileMQ systems address both terminal 
resource constraint as well as connection constraints 





Connection constraints 



Event based data replication, arising through the distributed client solution, also 
addresses connection constraints and is inherently session independent. 

Imposing session independence enables functions normally delivered in a session 
dependent manner than is not necessarily suitable for resource constrained devices to be 
deployed in a manner that is now fit for purpose. These functions include reliability of 
message delivery, sender authentication, message security, data rate flow control and 
packet routing. 



4/7- 
Figure 5 

A "Distributed Client 5 model 
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Figure 6 

The Small Client can include a terminal-side component, plus the client side MOM; the 
Small Server can also include a server-side component, plus the server side MOM: 
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Figure 7 



The Small Client can include a program - e.g. an e-mail application, plus plug-in linking it 
to the terminal-side component. 
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Figure 8 

The Small Client can also exclude the program, e.g. a contacts program. The terminal 
side component then communicates with the contacts program via the contacts database 
(with event triggers from that database being sent to the terminal side component): 
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Figure 9 

This is conceptually equivalent to the following middleware architecture: 
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